This application is generally related to digital processing systems, and more specifically to digital processing systems having multiple processing nodes.
In configurable systems, it is typically desirable to be able to execute multiple tasks concurrently. If some or all of these tasks have timing constraints (for example, if “real-time” operation is desired), the configurability of the system may be limited. This can be explained with reference to typical methodologies used to implement real-time systems.
Early real-time systems were often “hand crafted” in order to meet stringent timing constraints. In particular, real-time tasks that were to be executed concurrently were analyzed to determine their detailed timing requirements. Then, a real-time operating system was “built around” these tasks such that their timing requirements were satisfied. Because such real-time systems are tied so closely with the underlying tasks, they are not easily modifiable or extendible. For example, attempting to modify a task or add an additional task to the system could require a complete re-design of the system.
In order to make such systems “configurable,” the possible configurations are typically first determined and fixed, and then the system is designed to accommodate the timing constraints of the various possible configurations. If it is desired to add a new configuration or feature, detailed knowledge of the entire system, including knowledge of tasks that might be executed at any particular time, is typically required in order to ensure that the system can execute tasks in “real-time” under the various configurations. Alternatively, the entire system might need to be re-designed. Thus, the design of the system, and that of individual tasks that are to be executed, is typically tightly controlled. This can make it difficult to add new configurations to a device, and/or to permit third-parties to develop configurations for the device.
A more flexible approach to real-time systems is often referred to as the “scheduled reservation model.” Under the scheduled reservation model, the processor is viewed as a quantifiable resource that can be reserved like physical memory or disk blocks. But if two tasks require processor resources simultaneously, then one of the tasks will have to wait until the other is finished. If this task must wait too long, then it may not be able to execute in “real-time.” Thus, the scheduled reservation model cannot guarantee real-time execution of all tasks.
The scheduled reservation model provides a more flexible approach to design of real-time systems. In particular, design of a task or tasks does not require detailed knowledge of the entire system and/or other tasks. Thus, unlike “hand-crafted” real-time systems, task design need not be tightly controlled, and new configurations and/or features can be developed by those (e.g., third parties, etc.) without detailed knowledge of the system or of other tasks that may run on the system. For example, new features could be developed for a configurable device without requiring any changes to the underlying system or with other tasks previously designed for the system. Further, such features could be developed by third-parties with limited knowledge of the underlying system and/or of other features. As discussed above, however, “real-time” operation might not be guaranteed.
Another approach to real-time systems is often referred to as the “fixed priority model.” Under the fixed priority model, each task is assigned a priority level by developers. During operation, tasks are executed strictly based on their priority level. For example, a task with a higher priority than that of an executing task can interrupt that task, whereas a task with a lower priority than that of the executing task must wait until the executing task finishes. As with the scheduled reservation model, the fixed priority model cannot guarantee real-time execution of tasks (except for the highest priority task).
As with the scheduled reservation model, the fixed priority model provides a more flexible approach to design of real-time systems. In particular, design of a task or tasks does not require detailed knowledge of the entire system and/or other tasks. It does, however, require some knowledge of its priority vis-à-vis other tasks that may be executed by the system. Thus, task design need not be tightly controlled, but does usually require some degree of coordination. Thus, similar to systems employing a scheduled reservation model, new features for could be developed for a configurable device without requiring significant changes to the underlying system or with other tasks previously designed for the system. It may, however, require a reconfiguration of priorities of tasks that can be implemented on the device. Additionally, such features could be developed by third-parties with limited knowledge of the underlying system and/or of other features. But, “real-time” operation cannot be guaranteed.
Configurable systems having multiple processing nodes generally exacerbate the above-mentioned shortcomings and introduce others. It is desirable to provide techniques for use in configurable systems having multiple processing nodes that improve upon one or more of the above-mentioned (or other) shortcomings in the prior art.